On Wed, Jul 08, 2009 at 09:20:29PM +, Evan Hunt wrote:
Is there any reason these flags should not be set by default?
Yes, there is: the code as written uses the NSEC3PARAM record in a
way that, debatably, could be an RFC violation. We're planning to
correct this, and turn the feature
On Mon, Jan 04, 2010 at 01:43:52PM -0500, Kevin Darcy wrote:
named seems to use, by default, the OS hard limit on file descriptors,
even though the ARM says The default is |unlimited|. . When it starts
up as superuser, in theory it should be able to set both the hard and
soft limit to
On Mon, Feb 15, 2010 at 06:47:45PM +0100, sth...@nethelp.no wrote:
Have you *measured* the hit rate of your current BIND resolvers
with different cache sizes? How many queries per second are you
trying to support?
We do about 3,000 queries/second typically. I haven't measured query
The EDNS0 record is a pseudo RR that appears in the additional
section. dig reports that separately rather than in the additional
section, but the count of records in the header is correct.
--
Shumon Huque
University of Pennsylvania.
___
bind-users
planning
to phase out that platform, but maybe this thread will prompt me
to collect some debug info and send it out ..
--
Shumon Huque
University of Pennsylvania.
On Thu, Jul 08, 2010 at 10:43:47AM +0200, Niklas Jakobsson wrote:
Hello,
This was my first guess as well, but since the TSIG
== '__main__':
print ip6toptr(sys.argv[1])
- Cut here --
--
Shumon Huque
University of Pennsylvania.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
. al. ;-)
-JP
How about something like:
dig axfr zone | awk '$4 !~ ^NSEC$|^NSEC3$|^RRSIG$ {print}'
awk requires a tiny bit more typing, but the result is much more precise ..
--
Shumon Huque
University of Pennsylvania.
___
Please visit
pretty fast ..
I agree with Chris that a better mechanism for cleanup would be
useful.
--
Shumon Huque
University of Pennsylvania.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
On 12/5/13 11:49 AM, Jay Ford wrote:
I'm testing BIND 9.9.4-P1 on a RHEL6 system am getting this log message:
/etc/named.conf:56: couldn't add command channel 127.0.0.1#953:
address in use
That's with an rndc.key file in place no controls config, which implies
TCP 953 on 127.0.0.1 ::1.
On Fri, Mar 13, 2015 at 8:33 AM, Alan Clegg a...@clegg.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Are you interested in seeing a nice graph of what your BIND server is
doing when you aren't live-streaming the query log?
Shumon Huque released (quite a while ago, it seems
= dns.tsigkeyring.from_text({TSIGNAME : TSIGKEY})
update = dns.update.Update(ZONE, keyring=keyring,
keyalgorithm=dns.name.from_text(TSIGALG))
update.add(QNAME, 3600, 61, GEN_RDATA)
response = dns.query.tcp(update, SERVER)
print response.rcode() # should be zero
Shumon
uest about a year ago on this topic, and why BIND
should spread out the jitter:
https://gitlab.isc.org/isc-projects/bind9/issues/418
The changes first appeared in BIND 9.12.3 I believe.
Shumon Huque
___
Please visit https://lists.isc.org/mailma
e is above is a referral, but dig doesn't bother to follow
it and just terminates there.
Shumon Huque
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lis
Update: I've now filed this bug/issue:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1745
On Tue, Apr 7, 2020 at 8:11 AM Shumon Huque wrote:
> Hi folks,
>
> I thought I'd check here before filing a bug in the gitlab repo -- in case
> there is something I'm not underst
e with an NSEC3 param
using dynamic update or "rndc signing -nsec3param", and also use
dnssec-policy to allow for maintenance of the DNSSEC keys? Our requirement
though is that the signed zone needs to be NSEC3 out of the gate. At first
glance, if I'm understanding the new configuration
igfile.signed"). UPDATEs continue to go to the orig file
and ("inline?") signed deltas go into the signed file (well journal first
and synced later). It would probably be helpful to have the mechanics of
this new feature written up in detail so
behavior.
>
> You are right that at this moment dnssec-policy is not yet suitable for
> your use case. We will implement NSEC3 for dnssec-policy in 9.17 and
> backport it to 9.16.
>
> Best regards,
>
> Matthijs
>
> On 3/25/20 8:50 PM, Shumon Huque wrote:
> > On Wed, Mar 25, 2020
de: foo.test/NS
next resign time: Sat, 28 Mar 2020 08:40:06 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
Shumon Huque
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On Wed, Apr 1, 2020 at 8:36 AM Tony Finch wrote:
>
> This error behaviour is mostly specified by the UPDATE protocol (RFC
> 2136). It's worth reading the RFC becasue (as you have found) some of the
> behaviour is a bit surprising. For instance, adding a record that already
> exists is not an
On Thu, Jul 9, 2020 at 6:44 AM Daniel Stirnimann <
daniel.stirnim...@switch.ch> wrote:
>
> On 09.07.20 11:51, Klaus Darilion wrote:
> >>> So, how is the correct process to add an additional DNSKEY (only the
> public
> >> key is known).
> >>
> >> I think you are looking for `dnssec-importkey`.
> >
er the DNSKEY RRset with the imported ZSK
manually or with some scripting.
Shumon Huque
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subs
On Tue, Jul 7, 2020 at 2:21 PM Brett Delmage wrote:
> On Tue, 7 Jul 2020, Tony Finch wrote:
>
> > Reduce the size of responses to ANY queries, which are a favourite tool
> of
> > amplification attacks. There's basically no downside to this one, in my
> > opinion, but I'm biased because I
Fred,
Most of the details are in RFC 2308 (Negative Caching of DNS Queries).
On Sat, Apr 6, 2024 at 9:16 AM Fred Morris wrote:
> So the answer is in two parts.
>
> 1) An SOA record is required in the AUTHORITY section. The TTL on the
> negative answer is established by the TTL on this record.
23 matches
Mail list logo
